[レポート]DAT378:台帳データベースはどう使う?Amazon QLDB入門 #reinvent

本記事はAWS re:Invent 2018のSession「DAT378 - [NEW LAUNCH!] How do I know I need a ledger database? An Introduction to Amazon QLDB」のレポートです。

Amazon Quantum Ledger Database (QLDB) は re:invent 2018 の1日目のキーノートで発表された新サービスです。

[新サービス] フルマネージドの台帳データベースである、Amazon Quantum Ledger Database (QLDB) が発表されました！ #reinvent

Amazon QLDB is probably going to be one of my most favorite launches at #AWS #reinvent https://t.co/gM5BcavXNN

— Werner Vogels (@Werner) November 28, 2018

Amazon QLDB の発表と前後して発表されたブロックチェーンのマネージドサービス(AWS Managed Blockchain)とは別です。ご注意ください。

【速報】【新サービス】AWS Managed Blockchainが発表されました！ #reinvent

セッションについて

• 前半はトップダウンに台帳データベースが必要な背景
• 後半(22:00〜)はボトムアップに QLDB の動作原理

が解説されています。

本レポートではセッション後半を中心にまとめています。

セッション概要

Do you need a ledger database? Let's talk about the kinds of problems that Amazon Quantum Ledger Database (QLDB) can solve, and answer your questions about when and why you would use a ledger database. We'll showcase a presentation with benefits and use cases for Amazon QLDB.

スピーカー

• (前半)Chris de Kadt, Director, Amazon QLDB, AWS
• (後半)Andriew Certain, Sr. Principal Engineer, Amazon QLDB, AWS

メディア

本記事の画像はすべて YouTube 動画をキャプチャーしたものです。

Amazon QLDB のユースケース

Amazon QLDB は中央集権型な

• System of Record
• 台帳系サービス

に特化したデータベース。

具体的なユースケースは

• HR/給与支払い
  • 従業員の肩書
  • 給与支払い
• サプライチェーン
  • 製品の製造・出荷管理
• 政府
  • 車の登録手続き

ブロックチェーンと Amazon QLDB の違い

ブロックチェーンは分散台帳技術(DLT) を利用しています。

同じ台帳系技術のこの2つを比較します。

項目	QLDB	ブロックチェーン
管理	中央集権	非中央集権
データの更新	イミュータブル	イミュータブル
検証可能性	可能	可能
トランザクション処理	速い	遅い
データアクセス	SQL風シンタックス	独自

FAQ では次のように記載されています。

Q: Is Amazon Quantum Ledger Database a distributed ledger or blockchain service?

Amazon QLDB is not a blockchain or distributed ledger technology. [SNIP] QLDB is a ledger database purpose-built for customers who need to maintain a complete and verifiable history of data changes in an application that they own.

台帳データベースのコンセプト

• 台帳(Ledger)はジャーナル(Journal)とテーブルで構成される
• ユーザーはジャーナルにトランザクション(下図の黒丸)の追記しか出来ない
• 過去のトランザクションの変更・削除は出来ない
• ジャーナルをもとに以下のテーブルが更新される
  • 状態(current)
  • 履歴(history)

自動車登録手続きを例に Amazon QLDB の更新フローを考える

• 登録手続きをトランザクションとしてジャーナルに追記
• ジャーナルを更新すると、関連する以下のテーブルも自動的に連動して更新
  • 履歴(history.cars)
  • 現在の所有者(current.cars)

レコードの作成→更新→削除のライフサイクルを例に、具体的に確認します。

※注意: DMW は Department of Motor Vehicles のこと

レコードの新規作成

新規に対応するトランザクションログを作成。 ジャーナルにはこのトランザクションしか無いため、current と history は同じ。

INSERT INTO cars <<
{
  'Manufacturer' : 'Tesla',
  'Model' : 'Model S',
  'Year' : '2012',
  'VIN' : '123456789',
  'Owner' : 'Traci Russell'
}

レコードの更新

所有者が変わると、その所有者の情報でトランザクションログを作成。 履歴(history)に追記され、所有者(current)は新しいトランザクションのものになる。

UPDATE cars
SET owner = 'Ronnnie Nash'
WHERE VIN = '123456789'

レコードの削除

廃車などにより登録レコードを破棄する際は、削除に対応するトランザクションログを作成。 履歴を残しつつ、所有者はいなくなる。

DELETE FROM cars
WHERE VIN = '123456789'

伝統的な RDB を利用するなら?

レコード更新イベントに対してストアド・プロシージャを呼び出して

• 履歴(history.cars)
• 現在の余裕者(current.cars)

の2テーブル間の整合性を取るアプローチがよく採用されます。

以下の点に注意してください。

• データの整合性担保は RDB の基本機能として提供されているわけではない。RDBMS の機能を組み合わせて、実現しているだけ。
• QLDB はデータベースレベルで提供されている。

検証可能性(verifiability)を比較

RDB の場合

• 車が 2013/08/02 に犯罪で使われた
• 旧所有者は 2013/08/01 に売却したと主張
• 新所有者は 2013/08/03 に購入したと主張
• 登録管理している(伝統的な)データベースに照合すると 2013/08/03
• データベースの操作履歴も同じ日付

技術的に歴史を書き換えられる(改ざんできる)のであれば、データベースに残る日付(2013/08/03)は信用できない

Amazon QLDB の場合

• QLDB ではユーザーはテーブルを直接操作することは出来ない
• QLDB のテーブルはジャーナルのトランザクションをもとに更新される
• ユーザーが可能なジャーナル操作はトランザクションの追加のみ
• 過去のトランザクションの削除・変更はできない。
• トランザクション書き込み時にハッシュ値も記録
• 一つ前のトランザクションのハッシュ値も利用しているため、どこかのトランザクションが書き換わると、後続のハッシュ値も変わり、検証可能("any possible change in the log is immediately detectable by anyone")

データモデル

データにはどうやってアクセスするのか?

RDB で利用されるリレーショナルモデル

• 過去40年に渡り、広く使われてきた偉大なイノベーション
• すべてはトップレベルエンティティ
• アクセス時に各エンティティをJOINすればよいだけ

ネストされたデータ構造

• 最近のプログラミング言語はネストされた(高階)データ構造に対応している(JSON など)
• SQL と相性が悪い

QLDB はドキュメントデータモデルを採用

SQL とドキュメントデータモデルをどうやって両立させたのか?

• ネストされたデータへのアクセスをリレーショナルモデルの JOIN で表現
• 「.(ドット)」記法を拡張して実現

例えば次のようにデータがモデルされているとします。

Order {
  id : UUID
  shipping_address : Address
}

Address {
  state: String
}

Order モデルの shipping_address は Address モデルを参照しています。

Address モデルの state にアクセスするには

SELECT *
FROM orders AS o
WHERE o.shipping_address.state = 'WA'

今後の拡張

• トランザクション対応
• スケーラビリティ
• スキーマ制約(プレビュー時点はスキーマレスで制約なし)

最後に

Amazon Quantum Ledger Database (QLDB) は名前の通り台帳に特化した(purpose built)データベースです。

AWS お得意のフルマネージドサービスであり、SQL 風インターフェースまで用意されているため、Amazon RDS のような他のデータベース系サービスと同じような感覚で操作できるものと思われます。

RDB にいろいろアドオンして台帳に似たデータベースを構築していたり、イミュータブルで検証可能な台帳をほしいがためにブロックチェーンを評価しているユーザーには非常に刺さるのではないでしょうか。